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(54) Method and computer program product for interconnecting software drivers in kernel mode 

(57) A technique which overcomes inefficiencies in 
user mode processing of multimedia data by allowing an 
application running as a user mode process simply to 
start and connect multiple blocks of kernel mode func- 
tionality in the form of drivers or filters (separate logical 
blocks of driver executable code). Once the kernel 
mode filters are set up and connected, the user mode 
application need not be active until notified by the filters. 
Such notification may occur at the end of processing or 
at any relevant event chosen by the application as part 
of the filter initiation and set up. Furthermore, a user 
mode application may query a kernel mode filter or 
driver of its capabilities and requirements so that it may 
properly make the connections between the different fil- 
ters chained together to process a stream of data and 
request appropriate notifications. These connection 
may represent actual driver to driver data exchange, or 
remote connections. 
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Descripti n 

The field of the present invention is computer software driver development. The present invention relates to tools 
software frameworks, conventions, etc. to simplify code generation of drivers and provide standardized access points' 
More specifically, the present invention relates to standardized methods, computer program products and data struc- 
tures to interconnect in kernel mode software drivers written by different developers to allow continuous processing 
between the different drivers without making inefficient transitions back and forth between kernel mode and user mode 
Software drivers are normally built to control hardware or provide a software function and are run under an operat- 
ing system without much system overhead and relatively few restrictions. This allows the drivers to access hardware 
and service time critical processing requests more quickly since there is less system code running to ensure proper 
behaviour and "trap" invalid access or interference with another process running under the operating system 

Operating systems normally have different operational levels or "modes" depending on the amount of access and 
secunty features that are implemented. For example, normal application programs run at the lowest priority and have a 
full arrangement of security devices in place to prohibit interference with other applications. Hardware is only accessed 
through controlled interfaces. For convenience, this is referred to generally as "user mode." and the Windows NT oper- 
ating system, which will be used as part of an example implementation of the present invention hereafter supports a 
user mode. Similarly, most other operating systems of any complexity have an operating mode that is equivalent to 
"user mode." 

Drivers, on the other hand, run in a operating system mode that has a much higher run priority and little security 
protection to allow access to actual hardware that the drivers, in many instances, directly manipulate. Many applications 
are benefited by running in this looser and more performance-oriented mode, generally referred throughout in Win- 
dows NT terminology, as "kernel mode. " Again, other robust operating systems will have a functionally equivalent mode 
Because the general concept of a software driver contemplates controlling specific hardware, drivers are normally 
developed in isolation from one another and provided by the hardware manufacturer. For example software drivers pro- 
viding some I/O service associated with an add-in hardware card through a device definition need not communicate 
nor know the existence, of any other driver. 

In some circumstances, this dedicated approach to driver development and associated lack of communication 
capability between drivers forces processing preferable for kernel mode operation into user mode operation with the 
performance disadvantages associated therewith. 

An example of a program currently incapable of easily using kernel mode drivers, used throughout this application 
comprises graph building functionality that allows a user to select and connect together different processing blocks' 
called filters, to successively manipulate a stream of multimedia data. The data typically is a series of samples repre- 
senting sound or video, and the processing blocks may include decompression processing for compressed data spe- 
cial effects processing. CODEC functionality, rendering blocks to convert the data into analog signals etc 
as Such filters are typically located in user mode so that the graph builder portion of the program may'interconnect and 
control their operation and be responsive to user input and rearrangement of processing blocks Because of the con- 
sistent stream nature of multimedia data and the generation of large quantities of data, performance is a critical issue 
In a general purpose operating system, system performance as a result of repeatedly passing/switching back and forth 
between user mode and kernel mode and the implied security validation of such transitions can be so degraded as to 
40 prohibit certain multimedia applications. 

Furthermore, the processing blocks will many times have hardware associated therewith requiring multiple transi- 
tions between user mode and kernel mode components. Such transitions comprise another form of overhead that takes 
away from the overall multimedia processing system performance. When making transitions between user mode and 
kernel mode, there may also be overhead associated with copying the data between different buffers that would be 
45 unnecessary if the processing remained in kernel mode. 

Yet another detriment of making kernel mode to user mode transitions is the limited ways of scheduling the work 
tasks wrth the operating system. If work can be kept in kernel mode, system performance can be further optimized by 
taking advantage of more performance oriented scheduling methods, such as software interrupts and deferred croce- 
dure calls (DPC's). M 

Furthermore, it would be advantageous to allow different driver developers to create drivers that are connectable 
to one another by following a common interconnection scheme and definition. In this manner, any driver functionality 
written to a common interface could be interconnected into a system of functional processing blocks with all data tran- 
sitions occurring in kernel moda Furthermore, with a known specification, many different driver developers could 
develop interoperable and interconnectable driver software. 

The present invention provides a technique for interconnecting software drivers in a standardized fashion in order 
to prevent operating system mode transitions during processing of data and thereby enhance system performance 

The invention can provide a base mechanism for interconnectable software drivers that is extensible by third party 
cl svgI op6rs. 
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The invention can allow more performance critical processing to occur in kernel mode. 
The invention can allow a third party component to interconnect software drivers. 

Accordingly, a method and computer program product for interconnecting software drivers in kernel mode are pro- 
vided. A given driver or filter will support and define connection "pin factories'* that produce a pin instance of a certain 
5 type that may interconnected to other pin instances on other drivers to allow processing messages to be consecutively 
processed in kernel mode by the drivers without necessary resort to a user mode agent. In this way, data may flow 
entirely in kernel mode and be more efficiently processed without having the overhead of crossing into user mode. 

A third party agent desiring to connect compliant drivers will query the drivers of their capabilities. Such capabilities 
include what kinds of connection pin factories may be used to instantiate connection pin instances, including their rele- 
10 vant characteristics, such as type of data handled, data formats, transfer rates, medium or mode of transfer, input or 
output nature of a connection pin instance, etc. 

Once a third party agent, typically running in user mode, has queried the capabilities of one or more compliant driv- 
ers, the agent will determine the best connection characteristics for "chaining" multiple drivers together so that data may 
be optimally processed between them. This determination step occurs after all driver capabilities have been queried so 
is that the optima) connection criteria may be selected. 

The third party agent then interconnects the drivers by creating an instance of the necessary connection pins on 
each driver using the pin factory. The agent will specify a data format and a connection format as part of the connection 
pin instance creation. Furthermore, reference to previously created connection pin instances will be specified in 
requests for creating other connection pin instances in order to effectuate a connection between connection pin 
20 instances. 

In an exemplary embodiment implemented under the NT operating system, an actual connection pin instance is 
created by a create I/O operation that returns a handle to a "file." The create I/O request will contain the driver instance 
handle and reference to a data structure indicating data format and connection format for the connection pin instance. 

In order to create a compliant driver, a driver developer will support certain standard facilities to allow a user mode 
25 agent to query capabilities and make interconnections between drivers. In one embodiment, built on the Windows NT 
operating system, this is achieved by use of "sets" {i.e. . property, method, and event sets) that implement the desired 
functionality. 

A set is logically defined as having a GUID (globally unique identifier) to identify the set as a whole and a RUID (rel- 
atively unique identifier, e.g., relative within the set itself) for each element of functionality within the set. Each* set is 
30 associated with only one or two lOCTLs (IO Controls), and an IOCTL combined with a set specification controls all inter- 
action with the driver. 

As currently embodied, three types of sets are utilized, namely, property sets, method sets, and event sets. Prop- 
erty sets are used for managing values or settings within the driver, such as sound volume, transfer rate, etc, and use 
a single IOCTL with a flag indicating whether the call is getting a property value and or setting a property value. Method 

35 sets are used for managing the operations that a driver may perform, such as allocating memory, flushing buffers, etc, 
and uses a single IOCTL to call the specified method. Event sets are used for managing events associated with driver 
processing, such as device change notification, data starvation notification, etc, and uses two lOCTLs, one for enabling 
a specified event and one for disabling a specified event. 

To use a set, an I/O control operation is initiated using the specified IOCTL and reference to a data structure having 

40 the set GUID, RUID, and other necessary data. For example, setting a volume property on a sound card driver would 
entail an I/O control operation using a set property IOCTL, specifying the appropriate GUID for the property set having 
the volume setting, indicating the specific RUID within that set indicates the volume property, and containing the new 
volume setting value. 

To query the sets supported, a null GUID is used along with a query flag on a specified IOCTL for a particular set 
45 type {e.g., property set IOCTL, method IOCTL, or event enable IOCTL) and a list of set GUIDs supported will be 
returned. To query supported properties, methods, or events within a given set, the set GUID, set type IOCTL, and a 
query flag are used with the operation returning a list of supported RUIDs. 

By using the generic set mechanism, a minimum of functionality may be implemented to support a compliant driver 
but still allow unlimited extensibility. A set may be defined in a written specification that can be independently coded by 
so a multitude of different driver developers to create a system of interoperable and interconnectable drivers as long as 
particular sets are implemented. Furthermore, the specification can define mandatory properties, methods, and events 
that must be supported as well as optional properties, methods, and events that can be implemented depending on the 
driver functions and advanced capabilities. In addition to the basic minimum commonality required, driver developers 
may incorporate additional functionality by defining their own sets and assigning them a GUID. By being able to enu- 
55 merate supported functionality {i.e. . make queries for supported GUIDs and RUIDs ), a caller, such as a third party con- 
trolling agent, can adjust expectations or make appropriate compensation depending on the capabilities of the 
underlying filters. 

As used herein, the term "user mode" refers to a level of operation in an operating system where most user written 
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programs run. The user mode level of operation is typically the most secure level and has a significant amount of over- 
head to prevent one application program or process from interfering with another application program or process Fur- 
thermore, access to system resources is highly controlled through specific interfaces and run priority is generally one 
of the lowest, if not the lowest. 

r^^fr' 016 ter "\" k ? me 1 l "9**" refers to a ^ of operation in an operating system having significantly less 
restrictions than the user mode level of operation. Examples of kernel mode programs or processes would include soft- 
ware drivers for controlling hardware components. Typically, kernel mode programs are performance sensitive and 
therefore, have less operational overhead than user mode programs. Furthermore, access to hardware and many sys- 
tem resources is unrestricted or much less restricted than for user mode programs. In many instances, program code 
running in kernel mode relies on programmer discipline and conformity to convention in order to establish good system 
behaviour (e.g., not disrupting another program's address space, etc.). Another term used for kernel mode is "trusted" 
cooe. 

As used herein the term "driver" refers to software driver programs typically running in kernel mode. The term driver 
may also refer to the actual executable program that is loaded onto the operating system or a portion thereof that 
imparts certain functionality. Drivers are in many instances, though not necessarily, associated with some form of hard- 
ware. 

As used herein, the term "fitter" refers to a portion of the functionality found within a software driver, including the 
enbre driver itself, where connection points may be exposed for sending data through the filter. For example, a software 
driver may support a number of different filters or may have one single function. Furthermore, a number of filters from 
different drivers that are internally connected together and externally exposing connection points for input and output 
may collectively be referred to as a single filter. Also, in a more generic sense, the term fitter may refer to the operation 
performed, such as decompression, etc. regardless of whether that occurs in a software driver filter running in kernel 
mode or another piece of program code running in user mode. 

As used herein, the term "driver object" refers to an operating system entity, defined by the operating system for 
25 managing and making known a software driver as a system resource. 

As used herein the term "device object" refers to a system level entity defined by the system, for making known a 
portion of a drivers functionality available for use as a system resource and defines the driver functionality and availa- 

As used herein, the term 'file object" refers to an operating system entity, defined by the system, for managing an 
invocation of a resource specified by a device object. A file object provides a context for usage of a driver object Fur- 
! °u ,6Ct may bS hierarchical| y rela »ed to another file object if the previous file object is designated' as a 

c£m on asfrelm^Sata * ^ ^ ^ ***** USed ' n aH 1/0 operations that 

^m a ^ S c : US !^l h ! rein ■ t6rm " dafa " refers to any informatton that * processed through the interconnected kernel mode 
™JL ♦ £ '"I med ' a data reDresentin 9 ^deo. audio, text. MIDI, etc. but may also include control information 
SSST? J? r ? Z ap »* cat,ons - For exam P ,e - a kemal modefilter graph may be used in process control operations 
,ntorma,,0n ****** between the different filters is ^ to develop control signals for actuating 
machinery. While examples are given of media processing systems, other applications could in like manner benefit from 
the system of interconnected kernel mode filters explained herein. 
H T S J „ QhOUt l hiS specifica,ion ' description of the present invention is described within the context of the Win- 
dows NT operating system available from Microsoft®. Furthermore, familiarity with the Windows NT I/O architecture 
is Presumed in order to understand the preferred embodiment explained herein. A good tutorial of the I/O system as 

45 Z^SZ^pET ^ ^ be ^ " *"* "' nSide Wlnd ° WS NT " Witten * Helen Custe ' a "d 

di ^ Si °" °' the drivers and svstem entities such as file Ejects, device objects and driver objects are 

STl, f,! e PreS ?r ,nVent, ° n may be implemented °" other operating systems having analogous components, 
w^theror notthey use thesame terminology. For example, should another operating system have an entity that oper^ 
ates as a file object, it could be interpreted as a file object regardless of its actual title 

The present invention will now be described, by way of example only, with reference to the accompanying drawings 
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1 9Ure l iS „ a Pri ° r 8rt f ata flOW diaflram Sh ° win9 a system of interconnected filters and drivers under the direction 
of a contrd^g agent for bringing sound data from a disk file, processing the sound data in some form, and render- 
ing the sound data to be played through a speaker. 

SSTlf *ZT* a system /^'"Q to ^e present invention having the same purpose as that shown in Figure 1 to 
read sound data from a disk drive, process that data, and render that data to be heard on a speaker, wherein the 
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processing fitters and rendering are handled by interconnected kernel mode drivers, again under the direction of a 
controlling agent 

Figure 3 is a vertical relationship model shewing the relationships between driver objects, device objects and file 
objects as created and used in an operating system. 

s Figures 4A, 4B and 4C are logical block diagrams of a driver object, device object and file object, respectively, 

showing their logical relationship with the data structures and program code to route messages to appropriate proc- 
ess handling code and to validate the creation of new file objects according to the system of the present invention. 
Figure 5 is a flowchart showing the initial set up of the routing and validation componentry and the processing of 
I/O messages by the kernel mode drivers. 

w Figure 6 is a flowchart showing in more detail the processing of a controlling agent, the routing and validation mech- 
anisms, and specific create handler routines for creating a new file object. 

Figure 7 is a logical diagram showing the horizontal relationship between connected filters utilizing the file object 

structures in an operating system to effectuate such a connection in a standardized fashion. 

Figure 8 is a flowchart showing the processing steps taken by a controlling agent in user mode to create and con- 

75 nect the kernel mode filters or drivers of Figure 7 in order to effectuate a connection for processing I/O requests 
received from the controlling agent with processing continuing between different drivers (filters). 
Figures 9A and 9B are logical overview diagrams of the kernel mode drivers and connections used to create a 
chain of kernel mode filters under the direction of a user mode controlling agent to implement a system for reading 
sound data from a hard drive, processing the data with the kernel mode filters, and rendering the data to be heard 

20 through a speaker. 

Figure 10 is a flowchart showing the processing steps for creating the interconnected kernel mode drivers for the 
system shown in Figures 9A and 9B. 

Referring to Figure 1 , an example system is presented for reading a stream of sound data from a disk drive and 
25 rendering that sound data so that it may be heard through a speaker according to the prior art model. An amount of data 
is stored on hard drive 20 representing sound in the form of digitized sound samples. Alternatively, the source of the 
sound data stream may be digitized information coming over a phone line, digitized information from network or other 
communication packets, or other sources known in the art. The data stream is composed of digitized samples having 
time interval information associated therewith either by data format and convention or by explicit timestamp information 
30 attached to each sample. A kernel mode disk driver 22 interacts with the disk drive hardware 20 and is under control of 
a user mode reader program component 24. A controlling agent 26 manages the different components in order to effec- 
tuate the rendering of the sound data and may include dynamic graph building capabilities so that the different software 
components may be dynamically allocated in order to provide custom filtering or other processing paths as designated 
by an end user. 

35 The reader component 24 will interact with disk driver 22 using a standard I/O control interface of the operating sys- 
tem and will cause the compressed sound data to be read from the disk drive 20 into buffers allocated in user mode as 
part of the user mode process address space. Next, a decompressor component 28 will decompress the compressed 
data into its decompressed format for processing. As shown, this step is done entirely in user mode with the attendant 
lower priority and process behaviour safety mechanisms. 

40 The effects filter 30 will operate on the data to provide some special effect and will have an accompanying effects 
filter 32 operating in kernel mode. Furthermore, an effects processor 34 may be present or the effects filter may operate 
entirely in software emulating the actual hardware processor. In order to access the effects filter 32 the effects compo- 
nent 30 will use the system I/O control mechanism to transfer the data and control to the effects filter. Again, the kernel 
mode/user mode boundary is crossed in order to make this transition. 

45 The effects filter 32 will control the effects processor 34 and cause whatever special effect is necessary or desired 
to be made on the data. This may entail copying all the data from the effects component 30 down to the effects filter 32 
and again to the effects processor 34 depending on actual system configuration. While many software effects compo- 
nents have a hardware processor associated therewith, others function entirely within system software running on the 
host processor. 

so After control and the data is transferred back into user mode at the completion of the processing of the effects com- 
ponent 30, it is then transferred to sound rendering component 36. The sound rendering component 36 will transfer the 
control and data to the sound rendering driver 38 which in turn controls the sound card 40 in order to render the data, 
as processed and filtered, as sound through speaker 42. As can be readily seen, there exists a variety of transfers 
between user mode and kernel mode that add inefficiencies to the rendering of the sound data. Because of the timing 

55 sensitive natur of multimedia data, such as a continuous stream of sound or video, it is advantageous to reduce these 
inefficiencies and transitions of control as well as the multiple copying of data between different buffers. 

One embodiment of the present invention and used throughout will consist of a service provided on the Windows 
NT operating system architecture. This service is broken into different software components that a user of the system 
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will access. First, a user mode API is available that will include a routine for creating connection pin instances and nthpr 

10 trnmn^nl^IfT °' ** sy !l em of R 9 ure 1 the present invention will appear as shown in Figure 2 A con- 

mode drrvers made dynamically by a third party controlling agent (horizontal) interconnected kernel 
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" rectly create the connection pin instance. For example, file objects 72 and 74 represent connection pin instances for the 
fitter represented by file object 70 and are hierarchally related to file object 70. The connection pin instances, as repre- 
sented by file object 72 and 74, respectively, may be a data path into and then out of the filter instance (represented by 
file object 70) which can be used for connecting to other connection pin instances in forming a series of chained filters 

5 or other driver functionality. 

Just as a pin instance is represented by a file object having a hierarchial relationship to another file object repre- 
senting the fitter instance in order to provide context information for the pin instance, other file objects may be hierarchi- 
cally related to a pin instance in order to represent other functionality so that proper context information is available. 
Context information is necessary to distinguish one pin instance from another according to the individual parameters 

10 used in creation, such as pin data format, communication type, etc. 

Other operational entities, such as a buffer allocation mechanism, a timing mechanism, etc, requiring either an indi- 
vidual context or user mode control through a handle may also be represented by file objects. Furthermore, hierarchical 
relationships between the file objects {e.g., a buffer allocation mechanism associated with a particular connection pin 
instance) may be established if necessary by specifying a parent file object during creation of the child file object. These 

15 parent/child relationships exist to determine relationship and structure between the file objects representing the opera- 
tional entities. Additionally, a particular type of "parent" file object will only be able to produce certain types of "children" 
file objects, thus requiring the creation validation mechanisms as explained hereafter. Again, such file objects have cor- 
responding handles available in user mode that are returned to a client through a system API call such as NtCreateFile. 
The handles to file objects are used by user mode clients, such as a controlling agent, to communicate with the ker- 

20 nel mode drivers. The hierarchical chain of file objects, device objects, and driver objects allows the I/O subsystem to 
traverse back to the driver object through the hierarchically related file objects and device objects to arrive at the entry 
points into the actual driver code. Such entry points are references (e.g. t pointers) to functions in the software driver 
code. Furthermore, each of the objects in the object pathway between a particular file object and the driver object hav- 
ing the entry points to the software driver code provides important context information for the I/O subsystem in creating 

25 IRPs as well references into data structures used for properly routing IRPs according to the routing and validation 
mechanism explained hereafter. 

Handles for file objects and other system objects are process-specific and are the means by which a user mode 
process will communicate with an underlying object. It is interesting to note that multiple handles may be created to ref- 
erence a single underlying system object, such as a file object. This means that multiple applications may be feeding 

30 information to a pin instance as represented by a file object. 

One element of information that is important for interconnecting different drivers is the device object stack depth 
parameter. This will indicate the IRP stack location of a particular driver object. In this manner, a single IRP may be used 
and passed between interconnected drivers using the I/O manager, thereby providing a performance enhancement 
over separately creating and sending IRPs between the various interconnected drivers. Alternatively, each driver could 

35 create through appropriate I/O manager calls new IRPs for each successive communication and cause each new IRP 
to be sent to the next driver in the chain of interconnected drivers. 

Referring now to Figures 4A-4C, extensions to the system driver objects, device objects, and file objects are shown 
that allow validation of file object creation of differing types as well as I/O Request Packet (IRP) routing to appropriate 
handlers. Figure 4A shows a driver object 76 representing the executable code implementing one or more filters or 

40 other driver functionality. Within the driver object, the Windows NT architecture requires a reference to a create handler 
provided by the software driver developer. According to this embodiment, a multiplexing dispatch function 78 is refer- 
enced from the driver object 76 as the create handler and will be used to route messages to particular create handlers 
depending on the file object type to be created. Operation of the multiplexing dispatch function 78 will be explained in 
connection with the flow chart shown in Figure 6 hereinafter. 

45 In like manner, other handlers from the driver object will indicate a multiplexing dispatch function and, depending 
on implementation, they may be the same function. In other words, as explained in more detail below, each type of I/O 
handler reference {e.g. , read, write, device control, etc.) will point to a multiplexing dispatch function that uses the exten- 
sion data in a device object and the context information in a file object in order to route the message to the appropriat 
handler. The extension data in the device object that references a validation table will be used when no parent file object 

so is specified on a create operation. Otherwise, the parent file object context information will indicate the correct validation 
table. 

Figure 4B shows a driver object 80 which has a particular device extension area 82 that can be utilized as desired 
by the driver developer and includes driver specific information. At a defined location within the device extension area 
82 of the driver object 80 is a reference to a data structure, known as a file type validation table 84, containing string 
55 representations of file object types 86 and references to the associated create handlers 88 for each file type repre- 
sented. The create multiplexing dispatch function will the utilize file type validation table 84 to validate the file object type 
to be created and then turn control over to the appropriate create handler as will be explained in detail hereafter in con- 
nection with the cfiscussion of Figure 6. The string to be validated is found in the IRP create request and originates from 
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* request 96 are associated with t^ZSTjSSS lUS^9?21 ^ *!* * 71,6 d "" wl **** of ,RP 
will use this information to access the SroStaSSTSTS T«« a » ropnato ******** dispatch function 
structure known as a file type valioation ^inn te rLl, determining the correct create handler, a data 

and references 104 to ^ESSSS^J^tT^^ **" representa « ons * *ject types 102 
objects that have another file objS t ™ZTi!j?5!S St SilTSSS ■** ^ "* ^ ^ 

10 compared to the strings in the file object types 102 When SSTlEES'iEf ^ JT 686 "'^ by 3 Strin£> ** fe 
using a reference from the references 1 04 that i to «m£dt£. ?h^^L ??° C, ! led hand,er is accessed 
found, then the request is invalid and an errol tJESSS " e ^ tyPS Strin9 - * no match * 

Atste^^^^^^ 

75 tions. As shown in Figure 4A ^^^2^^^ ^ * W"*"'* 6 multiplexing dispatch func- 
other handler references in ^dn£E5££t£^i^ multiplexing dispatch function. In .ike manner, al, 
the particular handler as necessary MX^^T^^ m ,f P ,exjna **** functions germane to 

function that could in turn process i^^^^^jT^ ^ "** to the same multiplexing dispatch 

m 

Next, at step 108. each device object created as ran nf 
adjusted to reference the file type vaiid^ t^^ L^ll ^T^^ executable code installation will be 
requests will begin with the m^le^s^ F '? al,y ' at ste P 110 ' the Processing of IRP 

appropriate device object 80 US ' n9 the f " e type val,dation table 84 as referenced from the 

index^o^ 

within the proved create handlers accord^to ,Te S t^e ^ Sat^T *** ^ V ^° n tabtes «*"» 
dispatch table 94 and the file object type val^ZS^^rJTr^ f ^ 816 Created re P rese "tin9 the IRP 
the file context information 92 of 'the 5S25To5Si^S IST" * " ^ ^ 

tiona^aS^ 

a ™-,RPto^^^^^ 

Once the multiplexing dispatch function 78 has the IRP for the create reo,,^ a • 
m.ne if there is a parent file object. The information naea^Iw^K- Tf^" ' S made at step 1 16 10 deter " 
itself and originally be supplied by the u^nSSjSTrS determ,nafon * found within the IRP 

"parent" file object as partof the create riuS aSTh^NT^o Pr0C6SS wi " a h ^'e referencing the 

the "parent" file object ^ d th6 NT SyStem W,H create »» IRP h*™9 the correct reference to 

extend l^ZZT^^^^ '^ and *» *P«. function 78 uses the device 

118. Using the validations 84 Z ^I2KJS5^E^7^li ,- !^ 84 (See Fi£>Ure 4B > at ste P 
comparing the string in the request with the S^KC! 86 Ss ^ °* Cl * ^ 120 by 

If there is a matching string as determined at step 122 the amntato u ^, ■ 
erwise the create request is rejected at step 126 The ^TA^T ° *** handler ,s accessed a * step 124. Oth- 
be created, the file object at step 1 26. STSSS' " aCC6SSed 81 1 24 Wi " C ' eate ' 0r to 

asdeTinl^ 

uses the file context 92 from the parent *" multi P ,exin 9 *P** Unction 78 

For a create request, the n^Hwi^SSSKSS SS^TfSSf* ^ 94 ^ R9Ure 4C) * St6p 1 3a 

and the create handler wi.l fn^T^l^^^^^. Create h "*'. *• «• <*W 

is created at 140. 
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" the same file object structure as shewn in Figure 4C is used to explain interaction with both the parent file object and 
the validly created child file object While the same structure exists in both cases (once the new file object is created), 
they will be used differently and contain different information. 

Whenever a connection pin instance is created, a connection pin ID is passed that identifies the pin factory in the 
5 filter that "supports'* the creation of the pin instance. Those skilled in the art will note that the connection pin ID may also 
be validated as a string in a validation table in much the same manner as the tile object is validated and that other imple- 
mentation variations exist. 

In order to make connections between different drivers, a common mechanism must be present to assure that a 
given driver supports such interconnections. This common mechanism must allow discovery of filter capabilities includ- 

10 ing connection pin factory capabilities. Furthermore, such a mechanism should also be extensible to provide additional 
flexibility to driver developers. 

One mechanism chosen in the present embodiment for defining compliant drivers and allowing discovery of capa- 
bilities are identified "sets" of related items. This is a convenient mechanism to be used with existing I/O communication 
mechanisms. A set is logically defined as having a GUID (globally unique identifier) to identify the set as a whole and a 

is RUID (relatively unique identifier, e.g. , relative within the set itself) for each element of functionality within the set The 
set identifier and any other data structures necessary for operating with the chosen RUID item are passed as part of an 
I/O control call using the filter handle as a parameter. Only a small number of lOCTLs need to be allocated in order to 
implement a full system of functionality. As implemented, three different types of sets are established depending on 
their functions, requiring a total of four lOCTLs. Other implementations may use sets in a different manner. The partic- 

20 ular IOCTL will signal the handler for I/O control to interpret or use the chosen element (using the RUID) in a certain 
manner. Furthermore, control flags may be passed with the GUID and RUID to further specify control information. 

The first set type is a property set and is used in connection with values or settings found within the driver or on any 
associated hardware. Examples of such settings would be transfer rate, volume level, etc. One IOCTL is associated 
with property sets with a control flag differentiating between a "get" property and a "set" property command. In this man- 

25 ner the same data structure can be used to either set or get a particular property with the driver determining the action 
required based on the IOCTL used. The correct property is identified by the set identifier consisting of its unique GUID 
and RUID combination. 

Method sets are another type of set used and are a set of actions that can be performed by a driver. Only one 
IOCTL is needed to identify the method set with the correct method to be actuated identified by the unique GUID and 
30 RUID combination for the set identifier. Methods are used to control the driver and include such functions as initializing 
the driver for use, clearing buffers, etc. 

Event sets are used for managing events associated with driver processing, such as device change notification, 
data starvation notification, etc, or any other notification defined by the set that may be useful to a user mode applica- 
tion. Two lOCTLs are used, one for enabling a specified event and one for disabling a specified event, while any data 
35 structures necessary for a given event identified by a RUID can be shared whether enabling or disabling the event. 

To use a set, an I/O control operation is initiated using the specified IOCTL and reference to a data structure having 
the set GUID, RUID, and other necessary data (e.g., control flags, data structures, etc.)- For example, setting a volume 
property on a sound card driver would entail an I/O control operation using a property set IOCTL, a control flag indicat- 
ing a set property operation, the appropriate GUID for the property set having the volume setting, the specific RUID 
40 within that set indicates the volume property, and the new volume setting value. 

To query the sets supported, by type, an IOCTL for a particular set type (e.g., property IOCTL, method IOCTL, or 
event enable IOCTL) having a null GUID and control flags to indicate supported set enumeration are issued as part of 
an I/O command and a list of set GUIDs supported will be returned. To query supported properties, methods, or events 
within a given set, the set GUID, set type IOCTL, a null RUID, and control flags indicating enumeration of supported ele- 
45 ments are used with the I/O operation. A list of supported RUIDs will be returned as a result of the I/O operation. This 
will allow a third party agent to determine which, if any, optional elements of an implemented set are supported. 

The written specification of a set uniquely identified by a GUID allows a documented mechanism that both driver 
developers and third party controlling agents may use as an implementation guide. The third party developer will know 
of a given driver's capabilities based on response to queries and preprogrammed knowledge based on the abstract set 
so definition. Likewise, a driver developer may use the abstract set definition as a guide to implementing a set or group of 
sets providing known functionality to any third party agent. 

In order to provide the connection abilities described herein, a compliant driver must support certain sets. The fol- 
lowing tables illustrate some important kinds of information that may be supported in property set format and that can 
be used in implementing the present invention. The first table refers to properties about a connection pin factory that 
55 would be implemented by a filter, while the second table refers to properties about an actual connection pin instance 
that would be created by using a particular connection pin factory as a template. 
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TABLE 1 



Rlter Properties and Their Use 



Property 



Description 



Connection Pin Factories 



10 



15 



20 



25 



Connection Instances 



bsts the different types of connection pin instances that may be created on a particular 
^ aC distinguishable type referred to as a pin factory Note that this is not the total 
number of connection pin instances which could be instantiated on this device but the 
number of unique connection pin types, such as an audio input and audio output 



^ n K un * er of '"stances already created of a given connection pin factory as well 
ftSi 9 , ° f instances supported for that particular connection pin factory 

If the total cannot be determined until the filter is actually connected, this property will 
i rexurn a * l. 



, Usts th e Possible data flow direction of a connection pin factory with respect to a filter 
| < e -g- Into ,he fi«er. out of the filter, or either into or out of the filter. 



30 



3B 



Usts tte communication requirements for a given connection pin factory in terms of 
processing IRPs. Some connection pin factories may not be interconnected but have 
other forms of control mechanisms associated therewith such as a "bridge" to a file 
source for data that represents a source point on a graph. The bridge control mecha- 
nism would allow setting of a filename indirectly where information is stored. 
In an exemplary implementation, an agent (which decides which pin factory to use for 
making a connection pin instance) must be able to understand the intrinsic meaning of 

' S ! ° r . in E Ut " SOUrCe " 0r " both '" ^ ^S 6 " communication types 
for a connection pin factory. For example, a source connection pin instance requires a 
handle or reference to a sink connection pin instance, etc. 

In the communication type context, sink and source refer to the disposition of the con- 
nection p,n instance in processing IRPs. A sink would receive the IRPs for processing 
while a source would pass the IRPs onto the next appropriate processing component. 
There are two communication types that are neither sink nor source and represent end 
points in the connection graph. An end point represents the place where data either 
enters or exits from the connected filters. A none designation indicates that the con- 
nection type may not be instantiated while a bridge communications type refers to an 
end point that may be instantiated so that specific properties may be manipulated For 
example, a bridge end point that is part of a file reader will likely have a property that 
will contain the path and file name of a file that stores the data to be processed 



*° Data Ranges 



45 



so 



f™?«^ f T I*"" 8 th3t 8 connection fa<**y may support, including the 
format of the data, if relevant. In one implementation, a count followed by an array of 
data ranges, wh.ch the connection pin type may support, is used as part of the prop- 
erty In that implementation, if different data ranges are supported under different 
mediums or interfaces (see below), different connection pin factories are available on 
a particular filter to accommodate such differences. Furthermore, each data range 
structure may be extended for format specific detail such as number of bits and chan- 
■ neis. 

The actualdata format a connection pin instance uses is set during creation of the 
instance. The data range property is used to assist in determining what that actual 

ffj *1 UX6 be for a P articu,ar connection pin instance and is accessed or que- 
ried by a third party controlling agent. 



55 
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TABLE 1 (continued) 





Fitter Pr perties and Their Use 




Property 


Descripti n 


5 
10 


Interfaces 


Lists other set GUIDs indicating the supported interfaces on a particular connection 
pin factory. An interface is the type or types of data that may be communicated through 
a connection pin factory. For example, MIDI data. CD music, MPEG video, etc. would 
be interfaces in the sense that data has a particular convention and format that a filter 
could handle. Such interfaces also comprise protocols for submitting the data. An inter- 
face is independent of the medium by which it is communicated. 


15 


Mediums 


Lists the supported mediums on a particular connection pin factory. A medium is the 
way or mechanism by which information is transferred, such as IRP-based, sockets, 
etc. An interface may be defined on top of a variety of different mediums. In the pre- 
ferred embodiment and implementation explained herein, an IRP-based medium and 
file IO- based medium is used. 


20 


Data Intersection 


Returns the first acceptable or "best" data format produced by a connection pin factory 
given a list of data ranges. This approach is used to allow a third party agent to deter- 
mine data requirements when chaining different filters together. In one implementation, 
the data intersection property is used to determine the best data format produced by a 
connection pin factory given the constraint of a list of data ranges. The list of data 
ranges may be acquired using the data ranges property on another pin factory that will 
be connected as explained previously. 


25 
30 
35 




A third party controlling agent, which has no knowledge of the data type specifics, may 
use the data range list of one connection pin factory and return the "best" {e.g., first 
acceptable data format) data format on the current connection pin factory Although a 
set of ranges of the two intersecting connection pin factories could be returned, only 
the best format is returned by the driver. In this manner, the third party controlling 
agent can apply this "best" data format to the next driver in the graph in order to create 
a virtual set of connections before actually initiating the creation of connection pin 
instances and connecting the entire graph of f flters together. This allows the controlling 
agent to assess the viability of a particular filter graph selected by a user and point out 
potential problems to the user before actually connecting the graph. The data format 
returned can also be restricted by the formats available given the connections already 
made on the filter. 


40 




This property is capable of returning an error if a particular data format cannot be 
determined until an actual connection is made or if an intersection is dependent on 
multiple data formats on different connection points. Essentially, intersection informa- 
tion is provided while the property itself will return a data format. 
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TABLE 2 



C nnection Pin Instance Properties and Their Use 



Property 



State 



Description 



Describes the current state of the connection pin instance. Possible states include being stopped 
acquiring data, processing data, being paused or idle, etc. The state represents the current mode of 
the connection pin instance, and determines the current capabilities and resource usage of the 

The stop state is the initial state of the connection pin instance, and represents the mode of least 
resource usage. The stop state also represents a point wherein there will be the most latency in data 
processing in order to arrive at the run state. The acquire state represents the mode at which 
resources are acquired (such as buffer allocators) though no data may be transferred in this state 
The pause state represents the mode of most resource usage and a correspondingly low processing 
latency to arnve at a run state. Data may be transferred or "prerolled" in this state, though this is not 
actually a run state. The run state represents a mode where data is actually consumed or produced 
[i.e., transferred and processed) at a connection pin instance. 

More resolution iin control may be accomplished using custom properties depending on the purpose 
of the filter and the underlying hardware. For example, in order to make an external laser disk player 
spin up. one would set some sort of custom "mode" property specific to that class. Setting this prop- 
erty may also change the state of the device but not necessarily, depending on the effect of the mode 



Priority 



Data Format 



Describes the pnonty of the connection pin instance for receiving access to resources managed by 
the fifter and is used by the filter in resource allocation arbitration. This property, if supported allows 
a third party controlling agent to indicate the priority placement of the particular pin instance relative 
to all other connection pin instances of all other drivers which may share limited resources with this 
particular connection and instance. 

This priority property may also be implemented to allow an agent to set finer tuning of the priority 
T »t S ' n ? daSS * priOI% - For ^P 16 ' a P ri ° ri ty may have certain subclasses associated there- 
with. If two drivers competing for the same resources have the same priority class, then the subclass 
priority is used to determine resource allocation between the two drivers. If the subclass priority is 
also the same, then arbitrarily, the first connection pin instance will receive the resources 



Used to get or set the data format for the connection pin instance. 



Theprevious tables are given by way of example and those skilled in the art will appreciate that many different oroo- 
ertes and schemes may be implemented in order to create the connections between different drivel 2«T 
ment is the standardization factor so that different driver manufacturers or development groups may create that 
may be interconnected since they are able to implement the same property sets 

Another useful property set gives topology information for the internal relationships of input and output connection 

P, ! n SS'ies Z a oZf^ ThiS T^l™ *■ Stete r6,ati0nShip ° f inpUt Pin fertoriesand coCondTng ouS 
KSSrf 9 .u S 95 Wha * *** ° f P rocessin 9 "aPPens between the input and output pin factories 

SnT S^h fl^T" 9 * 31 ^ be diff6rent data transformations, data decompression; echo cancel 

t.on, etc. Such information is useful to an automated f Iter graph builder that will trace a hypothetical connectionoam 
using multiple fitters before making actual connection pin instances and connections. B^JftlSSKSJS 

pa^Tge^ 

Therefore, a compliant driver is simply one that implements the designated property set This allows a third oartv 
coMng agent to make queries and settings to the compliant fitter once tt is determined that a qIS^SSS Sh 

zx;x soai is to acquire enou9h informafon ° n tow to c ° nnect the ; s 

h, * e«n S! 9 * r 9 t!l! riC i et m 1 ecnanism - a minimum of functionality may be implemented to support a compliant driver 
S^SSSE T ♦ ^ rtens ' bility ; A set mav be def in «» ^ a wrrtten specification that can be IrtinSnCSdSE 
LZ^? f d " Ver deve, °P ers t0 create a astern of interoperable and interconnect i drivers asloS as 

partaila^ sets are implemented. Furthermore, the specif ication can define mandatory properties i«Siod?ind2r! 
that must be supported as well as optional properties, methods, and events that can b **S*£Z Tde^ndTng 
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- driver functions and advanced capabilities. Besides the basic minimum commonality required, driver developers may 
incorporate additional functionality by defining their own sets and assigning them a GUID. 

Referring now to Figures 7 and 8. an illustration of the process for connecting two kernel mode filters is illustrated. 
Figure 7 shows a logical block description wherein each filter instance and connection pin instance is represented by 
5 file objects Figure 8 is a flow chart illustrating the steps to creating the file objects and the appropriate connections. 

Beginning at step 1 44. an instance of Filter A 1 46 and an instance of Filter B 1 48 are created by a user mode agent. 
These are created using standard file system API for creating files with a particular device. Filter A 1 46 and Filter B 1 48 
will be compliant filters or drivers because of their implementing the appropriate property, method, and event sets to 
support the creation of connection pin instances and for querying the respective filter's capabilities in terms of sets sup- 
10 ported and connection pin factories defined for that filter. 

The third party controlling agent will then query Filter A 1 46 and Filter B 1 48, respectively, at step 1 50 to determine 
connection pin factories available and the attributes for connection pin instances that may be created therefrom. These 
attributes include, as mentioned previously, the connection format and the data format for each individual type of pin 
instance for each respective filter 146 and 148. The querying will be accomplished using the set based query mecha- 
15 nisms explained in detail previously. 

After querying such information, the third party controlling agent will determine the optimal connection format 
based on the ranges of data formats and connection formats previously queried. This determination occurs at step 152 
and places in the third party agent the ability to use the same filters in different ways according to the needs of a 
selected connection path. The third party controlling agent will use the data intersection property, topology information, 
20 and connection pin factories on both the fitters in order to determine how best to select data format and connection 
arrangements depending on the actual filter graph being made. 

Input filter pin instance 154 is created by the third party agent at step 156 using the optimal detection formation 
determined at step 152. Since input pin instance 1 54 is a file object, a handle will be returned from the create process 
that can be used for delivering I/O requests to the input instance 1 54. Furthermore, the creation of the input pin instance 
154 was validated and uses the routing and valicfity mechanisms shown previously in discussion with Figures 4A-4C, 5. 



25 



30 



and 6 

In order to finalize the connection, output pin instance 1 58 is created at step 1 60 using as a parameter in the NtCre- 
ateFile call the handle of the previously created input pin instance 154. The effect of thus creating the output pin 
instance 158 is to utilize the system file management and I/O management facilities to create an internal IRP stack 
structure that allows an original write command to be consecutively processed by the variously connected connection 
pin instances and filters in an appropriate order so as to facilitate direct data flow between the differing filters. This 
requires that the input pin instance be created prior to the associated output pin instance that will be feeding the input 
pin instance. 

The stack depth parameter of a device object controls how many stack locations are created for an IRP sent to this 
35 driver. A stack depth parameter is assumed to be one when a device object is initially created and may be modified 
thereafter depending on the whether multiple drivers are chained together. In the current system, modification occurs, 
if necessary, when an output pin instance transitions from the initial "stop" state to the "acquire" or other state. Connec- 
tion pin instance state transition is the mechanism that determines correct stack depth parameter information for proper 
IRP creation and treatment. 

In order to correctly allocate the internal IRP stack structure for a chained set of connection pin instances, it is nec- 
essary to transition the connection pin instances out of the stop state in a specified order; beginning with the last input 
pin instance (in this case input pin instance 154) and working consecutively backwards to an associated (e.g., con- 
nected) output pin instance (in this case output pin instance 158). If many filters are chained together, the deepest fil- 
ter's or bridge's input pin instance must be the beginning point of transitioning and building successively backwards until 
the initial output pin instance on a bridge or filter is set. In other words, the transition out of the stop state must occur 
backwards up the chain so that each connection pin instance gets the stack size needed after the previous connection 
pin instance. Typically, though not necessarily, a connection pin instance transitions from the stop state to the acquire 
state and for discussion purposes hereinafter transitioning to the aoquire state will accomplish the same purpose with 
respect to stack depth parameter adjustment as transitioning out of the stop state. 
so Once all pin instances are in the acquire state, stream reads and writes may be issued to the fitter graph. It is inter- 
esting to note that the system explained herein allows connection of associated input and output pin instances to occur 
in any order; only the transition from the stop state must occur in bottom up or deepest first fashion. Furthermore, the 
filter graph is reconfigurable to allow changes to be made after initial creation. When changes are made, state transi- 
tions need only occur on those connection pin instances that are in the stop state in order to assure correct stack depth 
55 parameter information. 

Connection pin factories found on filters represent places where a filter can consume and/or produce data in a par- 
ticular format. For exarrple, a particular connection pin factory may support a number of different data formats, such as 
16 bit 44 kilohertz PCM audio or 8 bit 22 kilohertz PCM audio. As explained previously, the connection pin factories and 
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their different capabilities such as data format can be queried from the filter using the aoproDriate orooertv set 
tTp^^ 

In a streaming environment, where a single stream write or stream read operation from a user mode anent win 
cause successive processing of the data through the connected filters two mair^meftods f^lSp rL^!n T ^1 

bac^rds up tothefirstfilterto receive the reused .RP oi to the filter that c^ZmP^^m ^ 
The current embodiment and implementation of the interconnected kernel malefilSs Siizes ^ sharinc ar,™ 
tageously to ease complexity in driver development, allow more robust drivers^ ^ 

processing. The "bottom up" pin instance state transition path wil. ensure S^SS^ii^Z^E 

w=mmmmmm 

softv^eXt^ R9U ? 10 ' the V"** Creati ° n ' <™"«*™- and state transition order of the 

Z5ZS^J?£ZZ Se JtSSr^E? 2 , ( S 9h : r ,evel ,09ical dia9ram * the interoonnec « ke -' 

Sn~f^ 

OKerne. mode f .Iters and compnses the processing steps encompassed by box 1 64 on the flow chart shown in Figure 
and ZZ 'in 2^1?? 9B ' haVjn9 a ^ rte ™ nn «*°"s made, the kerne, mode fitter system is ready for reads 

«*» beg,nn,n 9 a, aep ,68. ft. eo*o.in9 ag« ,70 w* ceate instates of ,eato m. iSliSiSlr (to 
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174 effects filter 176. and sound rendering filter 178 at step 180. Furthermore, attachment will be ^°J"^ 
reader filter 172 and a disk driver 182 in order to bring the data in from off of the d.sk dnve. Creation of each f ner 
See "achieved by the user mode controlling agent 1 70 by using standard I/O calls to open a He on the 
Se as foSnd in the device I/O directory hierarchy. Such a call will return a handle to a file object representing the 
instance of each filter. « i» 

At steD 184 the third party agent will query the effects filter 1 72. the decompressor filter 1 74. the effects filter 1 76 
and * S^renX ring £m 7? to determine the connection pin factory capabilities. These capab, t-« «** , what 
tends of ^put and outpul pin instances may be created, how many instances of each connects p.n factory the parte- 
S ilter rs^ppo^e data format supported on each connection pin factory, the medium or typeo^ 
path. etc. The capabilities are "queried" using the property set mechamsm explained m more detail 
kernel mode fittersare presumed to be compliant to the architecture since they support appropriate sets {e.g. . prop- 

^ AlTsuch query information at step 184 will be used to determine if a chained connection^ is^ssible be^een 
the respective filters by creating and connecting the appropriate connection pin .nstances. The third party agent win 
S3S types f of pin instances needed for interconnection in order to make a filter graph to accomphsh a g.ven 

PUff The determination of the connection format based on the supported data formats is determined I at step losing 
the topology information, data format, and data intersection properties on the filter, a hypothetical filter 
created Smce connection order is not significant, this need not be done but could save time whentry^gto bu.ld a filter 
graph. Should this hypothetical fHter graph be created without error, the third party agent will be assured M creating 
arTnterconnecting connection pin instances can be done with reliability. Because some quenes w.H return . «n» urtess 
an actual pin instance is created, it may be necessary to create such connection p.n instances before a hypothetical 
fme^ graph can be created that will return a reliable indication of viability. Again, the hypothetical filter graph may be 

tested before any interconnections take place. # . 

Once the colrect connection information is known, as determined at step 186 ^^ m ^ZZ\ Q 
ated and interconnected and as represented by the loop of processing steps enclosed by box 164 on Figure , 1a Ths 
foop contains processing steps that will begin at the input pin instance furthest away from tiie . source of the da ta streara 
™ S last input pin instance is referred to as the "deepest" pin instance and may be created tin*, followed by the output 
pin instance associated therewith. A connection, therefore, is the creation of an output p.n instance using the handle of 

30 3 P Te^~ Pin instance created successively awards prior to ^ectior , withthe 

associated output pin instance. Such a connection scenario is given by way of example and is not to be hrnbng of other 
poSbfe ways* connecting the respective output and input pin instances to form a connection between ker nel ™de 
f WeS accordTng to the present system. The filters may be connected in any order according to .mplementaton as long 
S handle from the input pin instance is used during creation of the connected output pin instance on another filter. 
FurVhermoti explained previously, changes may be made to the filter graph after initial creation (and ever , use y 

In the first iterSon of the loop, input pin instance 188 will be created at step 190. After 
the create function the third party controlling agent 170 will use that handle as a parameter in an NtCreateF.le call in 
^T^l^ui Pin insSnce 192 at step 194. By doing this through thefirst iteration, the sound rendemg .Iter 
178 is effectively connected to the effects filter 176 through the corresponding connection p.n instances 188 ^and 1 192 
iectively. In «* current implementation, the NtCreateFile call is "wrapped" as part of a function calhn an API made 
liable tc fthe user mode clients. This relieves the user mode developer of third party agents from needing to know as 
much detail and allows all relevant functionality be concentrated in a single user mode API. 

At step 196 the third party agent determines if there is any other existing input pin instances to be crea ed. If ther 
45 are an input pin instance must be created followed by the corresponding output pin instance on another .Iter. ^entu- 
aHy! a."conneclionswil.bemadeandthethird r^rty controlling agert 170 will prepare the fitter graph for streamed d 

^Sfashion. input pin instance 202 will be created on the second iteration of *e 

190 while the output pin instance 204 will use the handle of input p.n instance 202 as part of its creation at step 194. 

so ^hHdJri final iteration for this particular example, input pin instance 206 will be created fo.lowed by out- 

put pin instance 208 to finalize the connection. _ „ . . . .„ 

At step 197 the third party controlling agent 1 70 will transition each connection p,n instance from the stop state to 
the acqS sSe in preparatbn for streamed data processing through the filter graph. To correctly set the stack depth 
paraTeteH Tea* o'the device objects for the respective fitters, it is necessary to make the state transition beginning 

55 SThe "deepS* or last connection pin instance (e.g. . the last input pin instance to receive data for processing) and 
SuertialSng "up" the chain of interconnected kernel mode filters until arriving at the first connection pin instance 
ISTSSSSil Z instance that will provide data into the graph). The first filter or bridge w,l. create tte IRP ^wrth 
enough stack locations allocated so that the IRP may be passed successively through each kernel mode filter .n the 
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graph in an efficient manner. 

I-K^^^T* "° iSSUeS ^ Strea — 18 -^rrtes in order to process the data at step 

instance to save a referenceTm^^^ "? ™? Create hand,er for *• «** pin 

More particular.* this rtkJSSK «£ ES^^E^S" - ^ ^a?™ 1 ° r to access " 
accessed by the driver of the oulput pirHnsteSe SZEZSZL *£Z£Z? £ the '"P* P in **"ce to be 

The value of the stack depth p^^a^^ Z^tT^ I™ *° St0P *"* t0 the acquire or other s *te. 
^ckdep*^ 

tion -^irpSr^ informa- 
state transition in proper sequence, a single IRP may be «Z d«!n £»*hI , " 9 f " te,S and makin9 *» 
with no necessary communication into user mocT 6 Cham ° f ,ntereo ™«*a ™ers in kernel mode 

Each input instance is of the same type and the fiH^TnLc i ^ P '" mstance in terms 01 Processing. 
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Amethodofinterconnectingsoftwaredriverstoallowefficient kerne, mode processing ofdata comprising the steps 
opening one or more kernel mode drivers- 
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5 A method as claimed in claim 1. in which the connection pin instances include input pin instances to receive data 
for processing at the related driver, utput pin instances to send data from the related driver to a connected driver 
and bi-directional pin instances that both receive data for processing at the related driver and send data from the 
related driver to a connected driver. 

6. A method as claimed in daim 1 . in which the interconnecting step comprises, for each pair of interconnected pin 
instances, the steps of : 

receiving by a third party component, a first reference to a first connection pin instance related to a first driver; 
receiving', by a third party component, a second reference to a second connection pin instance related to a sec- 

P^sstng said first reference, by said third party component, to said second connection pin instance at said sec- 

d^to said'second reference, by said third party component, to said first connection pin instance at said first 
driver, said first and second connection pin instances to transfer data back and forth between connected 
respective first and second drivers. 

7. A method as claimed in claim 1 . in which the interconnecting step comprises, for each pair of interconnected pin 
instances, the steps of: 

receiving, by a third party component, a reference to an input pin instance, said input pin instance to receive 
data for processing at a receiving driver; . ... * * 

passing said reference, by said third party component, to an output pin instance, at a sending driver, said out- 
put pin instance to send data from said sending driver to said input pin instance of connected sad receiving 
25 driver. 

8 A method of interconnecting afirst and second device driver to allow said device drivers to communicate with each 
other using a kernel mode connection in a standardized and extensible manner, the method comprising: 

providing by a thiid party component, a data format and a connection format to a first device driver; 
creating, by said first device driver and in response to said third party component, a first instance of said con- 
nection format and a handle to the instantiated connection; 
returning by said first device driver, said handle to said third party component; 

providing, by said third party component said data format, said connection format, and said handle to said sec- 
35 ond device driver; and 

forming by said second driver and in response to said third party component, a second instance of said con- 
nection 'format utilizing said handle, thereby allowing said first driver to transmit data to said second driver 
entirely within kernel mode through said first and second connection format instances. 

40 9. A method as claimed in claim 8, which includes the steps of: 

querying, by a third party component, said first and second device drivers to determine what property sets the 
device drivers support; 

supplying, to said third party component by said first and second device drivers in response to a query, the type 
45 of connections each device driver supports; and 

determining, by said third party component based on the supplied connection information, how to make a con- 
nection between said first and second device drivers. 



30 



SO 



10. A kernel mode data processing system comprising: 
a data source; 



a data source; . , . 

a plurality of kernel mode data processing components including an originating component and a terminating 
component, the originating component reading data samples of a data stream from the data source; and 
kernel mode component interconnections between the data processing components to route the data samples 
ss from the originating component to the terminating component 

11. Adata processing system as claimed in claim 10. in which the data source comprises media containing data that 
is to be processed by the system. 
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2. A data processing system as claimed in claim 11, in which each of the kernel mode data processing components 
comprises at least one connection pin instances for forming a connection to another kernel mode data processing 
component and in which the kernel mode component interconnections are formed by interconnecting a connection 
pin instance of one kernel mode data processing component to a connection pin instance of another kernel mode 
processing component 
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